The growth of networks, specifically the Internet, is spurring a proliferation of applications based on peer-to-peer computer communications. In the older host-sever paradigm, a user took advantage of services provided by a more or less centralized corporate entity. In peer-to-peer communications, a user at one computing device communicates in real time directly with a user at another device. Computer telephony, teleconferencing, interactive games, and remote collaboration are just a few examples of increasingly popular applications that take advantage of inexpensive peer-to-peer communications.
It has long been possible to provide the illusion of peer-to-peer communications by means of a relay service. When two users wish to communicate, each logs on to the relay service and directs its communications to the relay service. The relay service receives the communications and forwards them on to their intended recipient. This approach is very useful as long as the amount of data transferred is small and the latency requirements are lax, but in cases that demand large bandwidth and real-time response, the relay service quickly becomes a traffic bottleneck. In addition, setting up and running a large relay service are quite expensive in terms of money and resources. Ideally, peer-to-peer applications can operate without the mediation of a relay service, but relays are still useful in providing connectivity when, for some reason, direct peer-to-peer communications are not possible.
Direct communications may not be possible if a “communications blocker” sits on the path between the peer computing devices. A firewall is a first example of a communications blocker. For security's sake, many users install firewalls between their computing devices and communications networks. Most firewalls protect computing devices by blocking incoming and outgoing communications except that which comes over specifically allowed addresses and ports. (Modern communications protocols, such as the Internet Protocol (IP), allow for the specification of source and destination fields called “ports,” in association with the source and destination addresses. Ports are often used to differentiate messages intended for separate processes running on a single computing device.) If a peer-to-peer application attempts to reach a computing device behind a firewall, the firewall may prevent communications from ever reaching the device. Even for communications directed to an open port on the firewall (e.g., port 80 is usually open), the port may be handling so much traffic from other sources that real-time response requirements cannot be met.
Another potential blocker of peer-to-peer communications is the Network Address Translator (NAT). Ideally, each computing device connected to the Internet is assigned a unique network address within the public address space. The growth of Internet connectivity, however, has rapidly depleted the supply of public addresses. To compensate, many computing devices today do not have public addresses but are, rather, assigned private addresses outside the public address space. Having disparate address spaces leads to complications, however. For example, a device with a private address cannot send a message to a device with a public address unless the private address is first translated to some public address. NATs automatically perform this translation by intercepting packets from the device with the private address and then replacing the device's private address in the packet header with the NAT's own public address. The packet is then sent along to the outside device with the public address. The NAT stores a mapping between the private address of the device behind the NAT and the public address of the device outside the NAT. When communications arrives from the outside device addressed to the public address of the NAT, the NAT refers to this mapping and replaces its own public address in the packet header with the private address of the device behind the NAT. By way of this mapping, the device behind the NAT can both send communications to and receive communications from a device in the public address space.
The NAT translation scheme is based on the premise that communications are initiated by the computing device behind the NAT. The NAT must first set up the translation mapping before it can know how to handle communications coming from the public network address space. Were a device in the public address space to attempt to initiate peer-to-peer communications by sending a message to the public address of the NAT, then, upon receiving the message, the NAT would search for a translation mapping for the sender's public address but would not find one. The NAT would discard the message, and the communications would fail. This problem is compounded when each device is behind its own NAT. In this case, neither device can initiate communications: while the NAT of the communications initiator sets up its translation mapping, the NAT of the recipient does not have an appropriate mapping and discards the incoming message. Communications never start. As NATs proliferate, this shortcoming impedes the spread of any application based on direct peer-to-peer communications.
Note that in the context of this application, “firewall” and “NAT” refer to services, not necessarily to specific devices. These services may be provided on separate hardware boxes, may be combined into one box, and may even be instantiated as software running on the computing device itself.
A known approach to the problem of NATs sets up a signaling exchange between a computing device behind a NAT and the NAT. (The discussion of the current paragraph applies as well to firewalls as it does to NATs, but only NATs are discussed to avoid repetition or having to repeatedly write “NAT/firewall.”) The device sends a message directly to the NAT. The message directs the NAT to allow the communications channel needed for a peer-to-peer application. However, this approach has its drawbacks. First, it forces the device to discover its NAT and to take the NAT's presence into account. Traditionally, devices did not need to know whether they sat behind a NAT: the NAT's operation was completely transparent. Second, because NATs operate automatically by intercepting communications and then discarding them or passing them along, no standard protocol exists to facilitate the signaling exchange. Adding that capability greatly alters the architecture of a NAT, which has often been an uncomplicated, firmware-based device. These considerations are compounded if the device sits behind a chain of multiple NATs or firewalls, some of which may be located far from it, such as at the facilities of the device's Internet Service Provider (ISP). The device may not be aware of all of these NATs and firewalls and may not have any means or permissions to communicate directly with them.
What is needed is a method for establishing communications that operates transparently to any communications blockers, e.g., firewalls, NATs, or what have you, in the communications path between peer computing devices.